home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Turnbull China Bikeride
/
Turnbull China Bikeride - Disc 1.iso
/
HENSA
/
INTERNET
/
ARCWEB
/
ARCWEB_191.ARC
/
!ArcWeb
/
HelpData
/
NetConf
Wrap
Text File
|
1996-12-10
|
9KB
|
223 lines
Instructions for configuring Network & EMail options
====================================================
There are currently 3 sections to the Network configuration window:
Fetchers, Proxies, Miscellaneous. There are 3 sections in the
EMail & News window: User details, E-Mail Gateways, News server
Note that any changes are not effected until you click on OK, and
they are NOT saved unless you click on Save Options.
Fetchers
========
This box contains 4 entries, HTTP FTP WAIS Gopher, the WAIS entry greyed
out. These indicate whether ArcWeb will respond to URLs starting http: ftp:
wais: gopher: respectively. If you do not have them selected, then you will
most likely get a 'No fetcher for ...' error whenever you try to access
anything non-local.
So leave the HTTP box switched on always, and probably leave the FTP one
switched on, unless you find that you are having trouble with ftp: URLs
crashing the machine. Also leave the gopher one switch on.
The reason why the WAIS option is greyed out and unselectable is because
ArcWeb doesn't (yet!) know how to do that itself. It needs a proxy server
to do it for it, which is explained in the next section...
Proxies
=======
This section contains 4 proxy definitions, and 1 'No proxy' definition.
Read the file WotIsProxy which was in the root of the ArcWeb archive.
Follow the instructions at the bottom of that file in order to read
the HTML version of my definition of a proxy.
Each line in this section of the window represents a different URL scheme
(HTTP, FTP, Gopher and WAIS). The large middle box contains the name of the
proxy server, and the small box contains the TCP port number on which the
proxy service is provided. The proxy is only used if the checkbox for that
scheme is switched on. You probably want to leave all 4 of these switched
on. If you are a Demon subscriber, then you want to ensure that all four
host/port pairs are set to www-cache.demon.co.uk and 8080 ; UK academic
community users want wwwcache.hensa.ac.uk in all the host boxes, and 8080 in
the HTTP, FTP and Gopher ports, and 80 in the WAIS port.
Whenever a request is issued, ArcWeb looks first at the proxy configuration
to see if the proxy for that URL scheme is configured and enabled (* except
see the No Proxy section below). If it is not, then it looks at the state of
the 'Fetchers' section. If the scheme is not enabled in there either, then
ArcWeb ignores the request and you will get a 'No fetcher for ...' error.
But if the 'Fetchers' section does mark the scheme as enabled, then ArcWeb
will communicate directly with the host who's name is given in the URL.
If the proxy *is* enabled for the scheme, then ArcWeb talks to the configured
proxy server for that scheme in preference to making a direct connection.
(*) The 'No proxy' box is used to avoid proxying requests to 'nearby'
machines (in network terms, not necessarily geographical distances).
Usually, if the scheme is enabled in *both* the 'Proxies' section and the
'Fetchers' section of the window, then the proxy will 'win' and be used in
preference to the direct connection method. However, if the host name used
in the URL matches the No Proxy entry, then the proxy will not win, and a
direct connection will be attempted.
ArcWeb will compare the *end* bit of the hostname with the contents of the
no proxy box in order to match the entries. So for example, if I set the no
proxy to "ac.uk" and I ask for "http://www.ecs.soton.ac.uk/" then this is
classified as a match, because the hostname ends "ac.uk". If I ask for
"http://www.demon.co.uk/" then this does not match. Similarly, if I ask for
"http://lilac.ukansas.edu/" (I don't know if this exists or not - it is only
an example) then this does *NOT* match, despite the ac.uk in the middle.
You can have a comma seperated list of match domains in the no proxy box,
eg. ac.uk,acorn.co.uk which will cause addresses to be compared with
"ac.uk" and then with "acorn.co.uk". An address has to not match any of
these entries in order to be proxied.
Miscellaneous
=============
The top 2 options in this section regard the actions that ArcWeb
should take at particular points of its execution.
If the 'Retain authentication' option is *OFF* (as recommended), then the
cache of user name/passwords used during the current session will be DELETED
as a security precaution. If the option in *ON*, then the data is retained
in the cache permanently (until you switch the option off and quit ArcWeb, or
manually delete the !WebCache.Data.Auth_DB file). If you are the only user
of your machine and it is relatively physically secure, then there is no harm
of switching on this option. For example, you can access the Clan Acorn
pages (if you are a member) and once you have entered the password then that
will be remembered in future sessions.
If the 'Ask for confirmation when using unofficial ports' is switched *ON*
(as recommended), then any attempt to use a particular scheme on a different
port from its well-known port will be intercepted and you will be prompted to
confirm the fetch. For example, the gopher protocol runs on TCP port 70. If
you find a URL such as "gopher://some.host.name:79/0hello" then this will be
trapped, since port 79 is not the standard gopher port (it is the 'finger'
port actually) and you will be asked to confirm that the connection should
go ahead. The result of continuing this fetch (in this example) will be to
actually perform the equivalent of 'finger hello@some.host.name' and won't
have anything to do with gopher at all. The results of talking to a server
using the wrong protocol are at best undefined.
NOTE: since many people who run http servers (under UNIX) do not have 'root'
user access, they cannot run the server on the well-known port for http
(which is 80). This is the reason you see http servers run on port 8080,
8001 and others. For this reason, http URLs are *never* trapped in this
manner by ArcWeb.
The second two options control some extra information that ArcWeb can
provide to remote servers.
Send Referer information to HTTP servers refers to a special header which
ArcWeb sends to the server to tell it the URL of the page you found the
link to the page you are fetching. (It is never sent if the page was
local:, or was typed in directly).
Send e-mail id to HTTP servers refers to the ability to send your e-mail
id with the request. There's not really anu harm in having this switched
on, unless you paranoid about security and people knowing what you are
looking at.
EMail & News Configuration
==========================
This window contains the information which ArcWeb requires in order to
service mailto: URLs and some news: or nntp: URLs. Note that this will NOT
download your mail or news from your provider as it is not a 'transport' for
any other application you might have. The gateways section will disappear as
soon as suitable support is built into other applications.
User Details
============
You should enter you full name in the Name box, and your complete e-mail
address in the Address box. This will enable services which are provided
by submitting forms via e-mail to respond to you! They are also used if
you send e-mail with ArcWeb.
E-Mail gateways
===============
You should enable the second option "Smarthost mail gateway", and enter
the hostname of your smart host mail gateway. This is the machine which
will accept any mail FROM you to anyone else. eg. Demon users can use
post.demon.co.uk as a smarthost.
MX mail delivery isn't implemented currently, hence it is greyed out.
This will usually be more efficient (the message will get to its
destination quicker), but may take longer to send if the MX host is
a long way away.
If you follow a 'mailto:' URL link, then ArcWeb will create a small text file
and open it in your current text file editor. Once you have completed the
e-mail, you should 'Save' the document *directly* from the editor onto
ArcWeb's icon bar icon, and it will then be sent. This is a *kludgy* way of
sending mail and much better support will be provided in the future by proper
e-mail programs. What You See in the editor is What Is Sent to the mail
server, so don't mess around with the headers except to change the subject
line. In particular, don't move the To: line because ArcWeb relies on
finding it there. There is *no* concept of adding taglines, signatures or
anything.
News Server
===========
The 'News Server' big box contains the name of a news server which is willing
to talk to you. If you have the News Server icon switched on, then ArcWeb
will attempt to retrieve specific articles from the given server. Note that
this is, again, a *kludge* so that specific articles can be read. It does
*NOT* provide any kind of menu of articles, threading etc. (yet!)
--
Stewart Brodie
10th December 1996